Method and system for manipulation of cost information in a distributed virtual enterprise

ABSTRACT

A method, system, apparatus, and computer program product for processing e-commerce information are presented. A business entity may transfer e-commerce agreements through an electronic marketplace. The business entity retrieves dependency information about a commercial transaction from an e-commerce agreement. The business entity incorporates the dependency information, e.g., dates, costs, deliveries, etc., as dependency relationships within a project model that represents a project for a product or service for sale by the first business entity. User input is received for manipulating a cost dependency relationship within the project model while constraining the user input to ensure that another type of dependency relationship is not incompatible with modifications to the cost dependency relationship.

CROSS-REFERENCE

This application is a Continuation of application Ser. No. 11/763,051,filed Jun. 14, 2007, now allowed, which is a Divisional of Ser. No.10/112,538, filed Mar. 28, 2002, now U.S. Pat. No. 7,469,216, both ofwhich are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

The present invention relates to an improved data processing system and,in particular, to an automated electronic business practice. Still moreparticularly, the present invention is directed to a system and anapplication for interfacing with a marketplace for electronic commerce.

DESCRIPTION OF RELATED ART

In recent years, a variety of electronic trading exchanges or electronicmarketplaces have been developed that allow businesses to conducttransactions across the Internet. In general, these electronicmarketplaces comprise a collection of separate business entities thatvoluntarily interface their private computer systems with the systems ofother business entities in the pursuit of some collective purpose orservice. In other words, buyers and sellers of goods and servicesorganize themselves into a digital marketplace for cooperative exchangeof goods and services. In fact, these services may include not only“real-world” services but also purely electronic or digital services.These electronic exchanges represent a neutral, centralized, beneficial,computer-mediated, marketplace in which competitors can conduct alimited portion of their business activities.

While some businesses offer proprietary middleware for facilitating theintegration of existing legacy computer systems with these relativelynew electronic marketplaces, there have been some initiatives towardsreducing the complexity of these interfaces in order to reduce the costof interacting with these electronic exchanges, thereby increasing thenumber of business organizations that might desire to participate in theexchanges. For example, the ebXML (electronic business extensible markuplanguage) set of specifications has been developed for creating anelectronic business infrastructure that is based on the exchange ofXML-structured data. The widespread adoption of standardized protocolsshould allow business entities to interface with electronic exchangeswith minimal cost and complexity. While the adoption of standards maysimplify the transactions between business entities, it should beexpected that these business entities will support multiple electronicexchanges for various competitive reasons as they seek advantages overother business entities.

The convergence of Internet-based electronic exchanges, applicationservice providers, and e-businesses allows an enterprise to conductbusiness in an increasingly dynamic landscape. From one perspective, anelectronic marketplace introduces an aspect of transparency or opennessto otherwise opaque or secretive business transactions, although itshould be expected that business entities will desire to maintain somelevel of opaqueness or confidentiality in their business transactions.

However, at the same time that business entities are interconnectingthrough these newly developed electronic exchanges in a web ofelectronic commerce, the employees within a business entity need theability to dynamically control various internal aspects of an e-commercetransaction within the business entity.

Therefore, it would be advantageous to provide new methodologies forallowing individuals within a business entity to control e-commercetransactions from an internal perspective of the business entity whileenabling a business entity to participate in external electronicmarketplaces or electronic exchanges.

SUMMARY OF THE INVENTION

The convergence of Internet-based electronic exchanges, applicationservice providers, and e-businesses enables the existence of adistributed virtual enterprise (DVE) in which a business entity haslittle or no physical assets and whose only e-commerce role is theability to link various customers and suppliers in a proprietary mesh ofbusiness transactions. Even though electronic exchanges significantlyreduce transaction costs and significantly increase the ability ofbusiness entities to gather competitive information, a virtualenterprise could still generate profits as an intermediate entity withinthese new electronic exchanges by protecting and employing institutionalknowledge.

A business entity may transfer e-commerce agreements through anelectronic marketplace. The business entity retrieves dependencyinformation about a commercial transaction from an e-commerce agreement.The business entity incorporates the dependency information, e.g.,dates, costs, deliveries, etc., as dependency relationships within aproject model that represents a project for a product or service forsale by the first business entity. User input is received formanipulating a cost dependency relationship within the project modelwhile constraining the user input to ensure that another type ofdependency relationship is not incompatible with modifications to thecost dependency relationship.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, further objectives,and advantages thereof, will be best understood by reference to thefollowing detailed description when read in conjunction with theaccompanying drawings, wherein:

FIG. 1A depicts a typical distributed data processing system in whichthe present invention may be implemented;

FIG. 1B depicts a typical computer architecture that may be used withina data processing system in which the present invention may beimplemented;

FIG. 2 is a block diagram that depicts typical data flow operationsbetween business entities;

FIG. 3 is a block diagram that depicts the use of a typicalebXML-compliant (electronic business extensible Markup Language)electronic marketplace between trading partners;

FIG. 4 is a block diagram that depicts a set of commercial entities anddata elements that are used to describe a typical electronic businesscollaboration in accordance with processes and events that are definedwithin the ebXML set of specifications;

FIG. 5 is a block diagram that depicts a distributed virtual enterprisein accordance an embodiment of the present invention;

FIG. 6 is a block diagram that depicts some of the data items that maybe included within a DVE object in accordance with an implementation ofthe present invention;

FIG. 7 is a block diagram that depicts some of the data items andmethods that may be included within an object-oriented DVE project inaccordance with an implementation of the present invention;

FIG. 8 is a block diagram that depicts an application supporting variousGUI views of the information derived from a DVE project;

FIG. 9 is a flowchart that depicts a process for using the DVE projectviews that are provided by DVE-enabled applications; and

FIG. 10 is a flowchart that depicts a more detailed process by which aDVE project examines the dependency relationships among its DVE objectsfor a proposed change in a DVE project.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is a set of methodologies and techniques to beused in conjunction with one or more electronic marketplaces that mayoperate on a variety of data processing systems via a variety ofnetworks. As background, a typical organization of hardware and softwarecomponents within a distributed data processing system is describedprior to describing the present invention in more detail.

With reference now to the figures, FIG. 1A depicts a typical network ofdata processing systems, each of which may implement some aspect of thepresent invention. Distributed data processing system 100 containsnetwork 101, which is a medium that may be used to providecommunications links between various devices and computers connectedtogether within distributed data processing system 100. Network 101 mayinclude permanent connections, such as wire or fiber optic cables, ortemporary connections made through telephone or wireless communications.In the depicted example, server 102 and server 103 are connected tonetwork 101 along with storage unit 104. In addition, clients 105-107also are connected to network 101. Clients 105-107 and servers 102-103may be represented by a variety of computing devices, such asmainframes, personal computers, personal digital assistants (PDAs), etc.Distributed data processing system 100 may include additional servers,clients, routers, other devices, and peer-to-peer architectures that arenot shown. It should be noted that the distributed data processingsystem shown in FIG. 1A is contemplated as being fully able to support avariety of peer-to-peer subnets and peer-to-peer services.

In the depicted example, distributed data processing system 100 mayinclude the Internet with network 101 representing a global collectionof networks and gateways that use various protocols to communicate withone another, such as Lightweight Directory Access Protocol (LDAP),Transport Control Protocol/Internet Protocol (TCP/IP), HypertextTransport Protocol (HTTP), Wireless Application Protocol (WAP), etc. Ofcourse, distributed data processing system 100 may also include a numberof different types of networks, such as, for example, an intranet, alocal area network (LAN), a wireless LAN, or a wide area network (WAN).For example, server 102 directly supports client 109 and network 110,which incorporates wireless communication links. Network-enabled phone111 connects to network 110 through wireless link 112, and PDA 113connects to network 110 through wireless link 114. Phone 111 and PDA 113can also directly transfer data between themselves across wireless link115 using an appropriate technology, such as Bluetooth™ wirelesstechnology, to create so-called personal area networks (PAN) or personalad-hoc networks. In a similar manner, PDA 113 can transfer data to PDA107 via wireless communication link 116.

The present invention could be implemented on a variety of hardwareplatforms; FIG. 1A is intended as an example of a heterogeneouscomputing environment and not as an architectural limitation for thepresent invention.

With reference now to FIG. 1B, a diagram depicts a typical computerarchitecture of a data processing system, such as those shown in FIG.1A, in which the present invention may be implemented. Data processingsystem 120 contains one or more central processing units (CPUs) 122connected to internal system bus 123, which interconnects random accessmemory (RAM) 124, read-only memory 126, and input/output adapter 128,which supports various I/O devices, such as printer 130, disk units 132,or other devices not shown, such as a audio output system, etc. Systembus 123 also connects communication adapter 134 that provides access tocommunication link 136. User interface adapter 148 connects various userdevices, such as keyboard 140, mouse 142, or other devices not shown,such as a touch screen, stylus, or microphone. Display adapter 144connects system bus 123 to display 146.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 1B may vary depending on the system implementation. For example,the system may have one or more processors, such as an Intel®.Pentium®-based processor and a digital signal processor (DSP), and oneor more types of volatile and non-volatile memory. Other peripheraldevices may be used in addition to or in place of the hardware depictedin FIG. 1B. In other words, one of ordinary skill in the art would notexpect to find similar components or architectures within a Web-enabledor network-enabled phone and a fully featured desktop workstation. Thedepicted examples are not meant to imply architectural limitations withrespect to the present invention.

In addition to being able to be implemented on a variety of hardwareplatforms, the present invention may be implemented in a variety ofsoftware environments. A typical operating system may be used to controlprogram execution within each data processing system. For example, onedevice may run a Linux®. operating system, while another device containsa simple Java® runtime environment. A representative computer platformmay include a browser, which is a well known software application foraccessing hypertext documents in a variety of formats, such as graphicfiles, word processing files, Extensible Markup Language (XML),Hypertext Markup Language (HTML), Handheld Device Markup Language(HDML), Wireless Markup Language (WML), and various other formats andtypes of files.

The present invention may be implemented on a variety of hardware andsoftware platforms, as described above. More specifically, though, thepresent invention is directed to a set of novel techniques to be used inconjunction with electronic marketplaces; typical electronic marketplacetransactions are described prior to a detailed description of thepresent invention.

With reference to FIG. 2, a block diagram depicts typical data flowoperations between business entities. Commercial transactions occur overa period of time, and each commercial transaction typically includes aset of actions by each party to the commercial transaction. Theseactions are typically recorded in a series of paper and/or electronicdocuments as evidence of the terms of agreement for completing thecommercial transaction. During various phases of a commercialtransaction, these documents are exchanged along with the correspondinggoods, services, and financial transactions that comprise the commercialtransaction.

FIG. 2 shows trading partner 200 and trading partner 201 that cooperatewith each other to complete one or more commercial transactions inaccordance with the typical data and material flow described below withrespect to steps 202-212. FIG. 2 also depicts a partial list of thedocuments, other data, and possibly material goods that may flow betweencommercial entities during various phases of multiple commercialtransactions. For example, a long-term contract (step 202) is created,thereby allowing the parties to a set of future commercial transactionsto forecast their component requirements (step 204) for completing theset of commercial transactions and those operations that are dependentupon the completion of the set of commercial transactions. Afteragreeing to the overall terms of the set of commercial transactions, thecommercial entities can also exchange planning documents (step 206) thatdescribe the logistics for the actual exchange, deliver, or receipt ofgoods and/or services.

Each exchange or delivery within the set of commercial transactions maythen be associated with a purchase order (step 208) that initiates aparticular commercial transaction, which includes an order and ashipment of materials (step 210) in this example. After the receipt ofthe materials, then a financial transaction occurs as payment (step 212)for the particular transaction. Multiple transactions may subsequentlyoccur in accordance with the previously negotiated long-term contract.

With reference now to FIG. 3, a block diagram depicts the use of atypical ebXML-compliant electronic marketplace between trading partners.A plurality of electronic marketplaces/exchanges have been developedthat use the Internet and World Wide Web to facilitate e-commerce amongcommercial entities; these electronic marketplaces coordinate thecommunication of multiple types of transactions and document types thatmay be exchanged between business entities, as depicted in FIG. 2. Asshown in FIG. 3, an electronic marketplace can be implemented inaccordance with the suite of ebXML (electronic business extensibleMarkup Language) specifications that are promulgated by UN/CEFACT(United Nations Center for Trade Facilitation and Electronic Business)and the OASIS (Organization for the Advancement of StructuredInformation Standards) consortium such that the electronic marketplaceis available for use by a commercial entity that accomplishes some orall of its commercial transactions using ebXML-compliant processes anddata interchange. For example, ebXML-compliant electronic marketplaces302 are open to commercial entities, such as business entity 304 and itstrading partners 306, for electronic collaboration processes. Moreinformation about ebXML can be found in the following documents whichare hereby incorporated by reference: ebXML Technical ArchitectureSpecification v. 1.04, February 2001; Business Process and BusinessInformation Analysis Overview 1.0, May 2001.

With reference now to FIG. 4, a block diagram depicts a set ofcommercial entities and data elements that are used to describe atypical electronic business collaboration in accordance with processesand events that are defined within the ebXML (electronic businessextensible Markup Language) set of specifications. Industry group 402defines a set of business processes and information models 404 that canbe used to describe, to structure, and to conduct commercialtransactions in an industry-specific manner. These processes and modelsare then stored in registry 406 for the benefit of any commercial entitythat desires to conduct an electronic business collaboration withanother commercial entity using the defined processes and models.Alternatively, the business processes and information models may becontrolled within an electronic business library that contains a catalogof these types of business documents such that the registry is directedmore towards runtime activities.

Trading partners 408 and 410 represent a pair of commercial entitiesthat use registry 406 in an electronic collaboration. Each tradingpartner generates a collaboration protocol profile (CPP), e.g., CPP 412or CPP 414, that is stored in registry 406. Commercial entities canperuse the CPPs from other commercial entities to determine whether ornot to enter into an electronic collaboration.

The activities related to defining and registering the businessprocesses, the information models, and the CPPs may be considered to be“design time” activities that support “run time” activities of actualelectronic collaborative activities. When two commercial entities decideto become trading partners, they exchange a collaboration protocolagreement (CPA), e.g., CPA 416, that defines the terms to which theparties have agreed for a particular collaborative activity. In thisexample, the trading partners may exchange goods and/or services 418during their collaborative activity. Although FIG. 3 and FIG. 4 depictexamples of electronic commerce activities with respect to anebXML-compliant marketplace, it should be noted that the presentinvention is able to be implemented with respect to specifications for avariety of electronic marketplaces/exchanges.

As noted previously, a major advantage of the recent development ofWeb-enabled electronic marketplaces is the ability to facilitateinformation exchange among trading partners. By using standardcommunication protocols (e.g., HTTP), standards for structuredinformation (e.g., XML), and standards for the exchange of commercialinformation (e.g., ebXML), these electronic marketplaces enablecommercial entities to find other commercial entities which desire toengage in mutually beneficial commerce. However, an electronicmarketplace operates between enterprises, so while electronicmarketplaces provide a business entity with external interfaces to otherbusiness entities, there are many data processing operations that anenterprise may need internally with respect to its own proprietary data.

The present invention recognizes that a business entity needs internalapplications and systems that allow personnel within a business entityto manipulate proprietary data in a manner that is consistent with theelectronic agreements to which the business entity has committed itselfwithin an electronic marketplace. Rather than constructing a middlewareapplication to tie together disparate information systems containingsupply-chain management information and electronic marketplacetransaction information, the present invention assists in maintainingconsistent relationships between cost information, schedule information,and electronic transaction information, as discussed below with respectto the remaining figures.

With reference now to FIG. 5, a block diagram depicts a distributedvirtual enterprise in accordance an embodiment of the present invention.Distributed virtual enterprise (DVE) 502 participates in e-commercetransactions in multiple electronic marketplaces 504 through electronicmarketplace interfaces 506. As noted above, different electronicmarketplaces may be implemented using a variety of well knownspecifications; hence, DVE 502 may require components to generate andreceive e-commerce information in accordance with the particularstandards that are used in the different electronic marketplaces. As DVE502 commits itself to various electronic agreements, e-commercetransactions, etc., such as CPA 416 shown in FIG. 4, these agreementsare stored in e-commerce agreement database 508. Appropriateauthorizations for manipulating these agreements and other proprietarydata within DVE 502 is stored in security database 510.

The e-commerce activities of DVE 502 are supported through the use ofDVE projects 512, DVE objects 514, and DVE processes 516. A DVE projectcontains one or more DVE objects. Each DVE object is an encapsulation ofinformation concerning physical goods, physical services, electronicservices, or combinations of these goods and services with DVE processesfor describing a particular component that can be obtained or aparticular task that can be accomplished in furtherance of the DVEproject in which it is contained. A DVE process is a container of one ormore steps or procedures that are performed in furtherance of the DVEproject in which it is contained. The DVE projects, DVE objects, and DVEprocesses can be created, viewed, and modified through DVE enablingengine 518, DVE scheduling engine 520, DVE costing engine 522, and DVEview assembly engine 524 using project view/control applications 526, asdescribed in more detail further below.

The manner in which an enterprise uses the DVE infrastructure may dependupon a variety of considerations, such as the enterprise'sorganizational structure or the mission statement of the enterprise. Ingeneral, a DVE project might be implemented for each product or servicethat is offered for sale by the enterprise, but a DVE project could beimplemented for a sales goal that spans many products or services withina division of the enterprise. In other words, the appropriateness of aDVE project is determined by the enterprise and not by the technicalimplementation of the present invention.

With reference now to FIG. 6, a block diagram depicts some of the dataitems that may be included within a DVE object in accordance with animplementation of the present invention. In the example shown in FIG. 6,DVE object 602 comprises multiple data items: type 604, which may referto a programmatic object type for an e-commerce service or to a class ofphysical object or physical task; name 606 for identifying the DVEobject; description 608 for a string containing alphanumeric data fordescribing the DVE object; significant dates 610, such as importantmilestone dates during the active lifetime of the DVE object withrespect to its DVE project; completion date 612 indicating the currentlyprojected completion date for the component or task represented by theDVE object based on other characteristics of the DVE object; dateconstraint range 614 indicating the earliest and latest possiblecompletion dates for the component or task represented by the DVEobject; completion cost 616 indicating the current completion cost forthe component or task represented by the DVE object based on othercharacteristics of the DVE object; and cost constraint range 618indicating the maximum and minimum possible costs for the component ortask represented by the DVE object. Other data items, properties, andmethods could be included within a DVE object depending upon theimplementation of the DVE system.

In one embodiment, a set of DVE objects can represent an encapsulationof parts or process steps in order to define the specifics of a productcomponent. A set of DVE processes can represent components, steps, andprocedures for the creation of a defined result of particular importanceto a DVE project. For example, various manufacturing steps, processes,and parts could be aggregated into a set of DVE processes, and the DVEprocesses could be linked together via temporal and/orpositional/ordering relationships within a DVE project. A DVE projectcan then integrate the dates, costs, marketing assumptions, andnegotiated agreements for a product or service. The project can bedisplayed in a number of formats using various GUI console applications,such as applications 526 shown in FIG. 5. To model potentially desirablechanges in a given project, a copy of a project manipulated within anapplication, and the application can honor the constraining dependencyrelationships among the data items. If necessary, the dependencyrelationships can be broken in order to model other completionscenarios, and the copy of the project completion model with themodified DVE relationships can be saved for viewing and/or analysis byother enterprise personnel and/or applications in order to determine thefeasibility, profitability, desirability, etc., of alternate projectcompletion scenarios. For example, a sales manager could createalternate projects with different costs and schedules that may representdifferent profit and/or marketing goals, and a manufacturing managercould then review and/or modify the alternate scenarios to provide amanufacturing perspective on those scenarios.

A major advantage of the present invention is the fact that theindividual data items that are stored within a given DVE object, DVEprocess, or DVE project can be derived from actual e-commercetransactions and/or agreements. Hence, the cost and schedulingconstraints that are manipulated by the viewer applications representthe constraining relationships and/or dependencies within the e-commerceagreements to which the enterprise has committed within an electronicmarketplace. In this manner, various enterprise personnel do not wastetime and resources analyzing project scenarios that might be desirableor feasible from the enterprise's perspective yet violate negotiatedagreements; in other words, the alternate project scenarios might beundesirable or unfeasible from a trading partner's perspective. Whenalternate project scenarios are found to be particularly compelling toan enterprise, however, then the present invention provides the abilityto automatically generate modified e-commerce agreements, therebyproviding a basis for automated renegotiation of those e-commerceagreements.

With reference now to FIG. 7, a block diagram depicts some of the dataitems and methods that may be included within an object-oriented DVEproject in accordance with an implementation of the present invention.To create a system that will enable and constrain the efficientfunctioning of a DVE, the present invention supports an applicationenvironment that allows for rapid adjustment and evaluation of variousaspects of developing, manufacturing, selling, and marketing products orservices. Depending upon the system implementation, various DVE projectclasses and subclasses could be created and used, but FIG. 7 shows anexample of an object-oriented DVE project model. Other data items,properties, and methods could be included within a DVE project dependingupon the implementation of the DVE system.

DVE project 702 may be implemented as an object with included data itemsand methods for operating on the object. DVE project name 704 identifiesa particular project among multiple projects that a DVE may have activeat any given time, DVE project description 706 provides a summary of theproduct or service that is being developed within a given projectobject. Security object 708 supports various security issues withrespect to a given project, such as the determination of theauthorization of role access or group access to a given project forparticular enterprise personnel. DVE object aggregation vector 710 is avector of the DVE objects that comprise the DVE project, as describedabove.

Change-notification vector or registry 712 is an aggregation of the DVEcomponents that require notification of changes or modifications to theDVE project; as described in more detail below, various completionscenarios for the DVE project can be performed by authorized personnel,and whenever a modification to a DVE project is requested by committingan alternate completion scenario for the DVE project, thechange-notification registry determines what other components, projects,trading partners, etc., need to be notified of the modification, DVEenabling methods 714 are the supporting methods for modifying a DVEproject. As an example, change-impact method 716 is responsible fordetermining the DVE objects and e-commerce agreements that would beimpacted based on proposed change to a DVE project, thereby allowing anenterprise employee to understand whether a proposed change isfar-reaching in its effects. If the enterprise has associated multipleDVE projects, then the impacts of a change on a particular project couldbe cascaded through associated projects to view enterprise-wide impacts,which would be helpful for understanding enterprise-wide resources, suchas assembly-line utilization, etc. Change-limit method 718 isresponsible for allowing an enterprise employee to place a limit or lockon a particular DVE object such that it remains invariable whileproposed changes to other DVE objects or DVE projects are contemplated.Change-view method 720 supports the multiple views that are permitted ona DVE project, which are described in more detail below.

Scheduling object 722 encapsulates known aspects of project schedulingfor DVE project 702, particularly with respect to business policies,goals, and considerations of the DVE enterprise that is implementing theproject represented by DVE project 702. Timeline display method 724supports the viewing and manipulation of various aspects of the scheduledates associated with DVE project 702.

Marketing plan display method 726 supports the viewing and manipulationof marketing information that can be derived from DVE project 702. Forexample, key schedule dates that might be useful for marketing a productor service can be tagged, highlighted, restricted, or controlled bymarketing personnel such that these schedule dates cannot be manipulatedfrom a financial or technical perspective without consulting marketingpersonnel because advertisements and other marketing material will beproduced or distributed based on these schedule dates. Since theenterprise may have contracts or other types of agreements with variousmarketing-related trading partners, such as creative agencies orpublishing companies, the integration of marketing considerations intothe DVE project object allows all possible enterprise-wide affects to beviewed and manipulated along with financial and technical aspects of aproject.

Supply chain display method 728 supports viewing and manipulation ofsupply-chain information with respect to DVE project 702. Although eachsupply-chain component can be represented by an individual DVE objectthat is able to be viewed and manipulated like other DVE objects, supplychain display method 728 allows particular emphasis to be placed on asupply-chain as a whole such that an entire supply-chain can be viewedand manipulated. This is particularly helpful to enterprise personnelbecause physical components for a project cannot be manipulated likevarious abstract properties and considerations, such as policy ormarketing goals, which makes the supply-chain more important in manyrespects. As an example, certain processes must have a physicalcomponent on which to operate, and the non-existence of the physicalcomponent cannot be considered as acceptable; for instance, a video-gamecontroller might be useless without a CD-ROM drive, and the supply-chainthat provides the CD-ROM drive would be considered as critical tocertain production milestones. In contrast, certain financial goals canbe manipulated by management even if the impact is determined to beclearly negative. For example, management can decide to produce and sellan unprofitable video-game controller system as one DVE project, whereasas a different set of profitable DVE projects for software game titlescan be scheduled for sale after the delivery of the associatedvideo-game controller. The manipulation of the financial goals of thevarious DVE projects is an abstract consideration that can be controlledas desired by the enterprise management, whereas possession of physicalcomponents for the physical system to be sold is not an option that canbe controlled by the enterprise management.

Agreement display method 730 supports viewing and manipulation ofsignificant dates within the e-commerce agreements to which anenterprise has committed itself within an electronic marketplace insupport of DVE project 702. Since the enterprise may have many contractsor other types of agreements with various trading partners, theintegration of legal or e-commerce transaction considerations into theDVE project object allows all possible e-commerce affects to be viewedand manipulated along with financial and technical aspects of a project.For example, after contemplating a schedule change to a component in DVEproject 702, the enterprise management may discover that the schedulechange is easily accomplished from a technical perspective. Upon furtherconsideration, management may determine that the contemplated changeprovides a larger profit, and the management may desire to implement thecontemplated change. With agreement display method 730, the enterprisemanagement would be able to determine whether the contemplated changewould require few or many e-commerce agreement changes. Without suchinformation, the enterprise management might commit itself to a newcompletion scenario for DVE project 702. However, with such information,the management might be able to understand that a large number ofagreements are going to be changed to accomplish the new completionscenario, which increases the risks that the new completion scenariomight not be completed in accordance with the contemplated schedule. Inother words, agreement display method 730 allows the management to viewthe enterprise's dependence on external trading partners in theelectronic marketplace, which inherently comprises risks that areoutside of the control of the enterprise.

Costing object 732 encapsulates known aspects of project costconsiderations for DVE project 702, particularly with respect tobusiness policies, goals, and considerations of the DVE enterprise thatis implementing the project represented by DVE project 702. In a mannersimilar to agreement method 730 in scheduling object 722, agreementdisplay method 734 supports viewing and manipulation of significantcosts within the e-commerce agreements to which an enterprise hascommitted itself within an electronic marketplace in support of DVEproject 702. Component cost display method 736 supports the viewing andmanipulation of individual costs that are associated with DVE project702 and its DVE objects. Financial roll-up method 738 supports theviewing and manipulation of costs that are associated with varioussubsystems or other object groupings within DVE project 702. Thisparticular method is useful for various intra-project costconsiderations, such as whether the cost of a set of components withinDVE project 702 might be easily reduced by replacing the set ofcomponents with a single subsystem that could be purchased by a tradingpartner within an electronic marketplace. Cost limit display method 740supports a function in which an enterprise employee can place a limit orlock on the cost of a particular DVE object such that it remainsinvariable while other proposed cost changes to other DVE objects or DVEprojects are contemplated.

With reference now to FIG. 8, a block diagram depicts an applicationsupporting various GUI views of the information derived from a DVEproject. Another major advantage of the present invention is that theDVE infrastructure supports DVE views, which allow enterprise personnelto execute “pulls”, i.e., specific extractions of information, againstDVE projects for specific purposes. This allows different employees toview the project in terms of their participative role within the projector organization, thereby allowing an employee to think of the project intheir own restricted terms.

As mentioned above with respect to FIG. 5, DVE projects, DVE objects,and DVE processes can be created, viewed, and modified through DVEenabling engine 518, DVE scheduling engine 520, DVE costing engine 522,and DVE view assembly engine 524 using project view/control application802. The project view and control application invokes methods within theDVE engines as necessary to incorporate functionality for processingvarious DVE objects. In particular, information from multiple DVEe-commerce agreements 804 and a particular DVE project 806 can beretrieved for viewing and manipulating within project management console808, enterprise management console 810, finance console 812, and humanresource console 814. Other views could be supported in accordance withthe organizational structure of the enterprise, the structure of theproject, or various other considerations. In one embodiment, the DVEengines can create XML representations of specified aspects of the DVEprojects for viewing within browser-like applications. The types ofviews that are created and the types of changes that are allowed maydepend upon the user's authorization parameters as controlled by thesecurity objects within a DVE project or by the overall securitysubsystems that are employed by the enterprise.

As mentioned above, various types of completion scenarios for a DVEproject can be contemplated by enterprise personnel by generating a copyof a DVE project and then manipulating various aspects of the DVEprojects, such as costs and schedule dates. The contemplated changescould be factual, such as pre-negotiated real increases in price thatare derived from proposed e-commerce agreements. In other cases, thecontemplated change may be a estimates based upon heuristics, such asexpected labor rates. For purely fictional scenarios, the contemplatedchanges may be flagged as such; parameters would be attached to DVEobjects for subsequent actions to be taken to determine whether thefictional changes could be implemented, such as requiring a purchasingagent to call a supplier or initiating an automated query that must beanswered within a preset time limit.

The various views of the DVE projects could be tailored for specificroles within the enterprise, as illustrated in the following scenarioconcerning the manipulation of market delivery information.

In this example, a marketing manager receives a market survey reportstating that reductions in capital spending are abating and thatspending for IT resources should grow substantially in the followingfiscal quarter. The marketing manager opens a DVE-enabled applicationwith a marketing view of a DVE project in accordance with the marketingmanager role of the employee as supported by the DVE view assemblyengine. The marketing manager may see that the DVE project is onschedule for delivery later in the fiscal year, which would misssignificant sales opportunities in the next fiscal quarter. In order tocapture those sales opportunities, the marketing manager uses themarketing view to manipulate alternative completion scenarios for theDVE project to see whether the completion dates for the DVE project canbe set within the next fiscal quarter. The DVE-enabled application usesthe DVE scheduling engine to determine whether the requested completiondates that are input by the marketing manager using GUI objects withinthe marketing view are valid given the constraints that are built intothe DVE objects within the DVE project.

A purchasing agent's view of the DVE project may show that the newlyproposed completion dates can only be accommodated by acquiring parts atan earlier date than had previously been negotiated with a tradingpartner. The purchasing agent's could request an accelerated deliveryschedule for parts, and the purchasing agent's view would highlightdependencies on allocation of storage space, If the storage space isover a tolerance constraint set in the DVE objects, the marketingmanager could get a notification for review of the DVE project based ona potential delay being introduced for a decision or informationrequired from purchasing. After the purchasing agent is able to providethe space, the DVE project would signal reconciliation, register thechange, and notify the marketing manager that the potential delay hadbeen resolved.

The personnel manager's view, i.e. the human resources view, would beable to show that a contemplated or proposed change introduces arequirement for a number of hours of labor from machinists who need towork on a specific physical component; the number of hours may be anon-negotiable dependency condition in a particular DVE object, and thepersonnel manager is not able to substitute other skilled workmen for aparticular task based on labor union agreements. Hence, if the personnelmanager decides to implement the proposed change, additional labor mustbe made available either from the union pool or from another project. Inthis manner, the requirements of one DVE project would ripple into theanother DVE project within the enterprise. Therefore, prior toimplementing the proposed change, the personnel manager might need toobtain authorization from other managers that are responsible for otherDVE projects.

At later some point in time, the financial manager's view would show theaccumulated cost effects of the consequences of the proposed changesthat are being contemplated or requested by the purchasing agent or thepersonnel manager. The expected income from the DVE project for the nextmonth could be displayed within the financial manager's view in additionto the increased shipping costs from the early ship date requested bythe purchasing agent and the increased labor costs due to additionalovertime and additional personnel as determined from labor unionagreements and approved by the personnel manager. In addition, thefinancial manager could view other impacted DVE projects, such as thedelay in the ship date of the other DVE project that would suffer from areduction in personnel in addition to a projected revenue decline forthe other DVE project. The financial manager can reject the proposedchange, but if the proposed change is accepted, then consequences of theaccepted change cascades through the DVE objects within the DVE projectand any other impacted DVE projects.

As mentioned above, a major advantage of the present invention is thefact that information within DVE objects, DVE processes, or DVE projectscan be derived from actual e-commerce transactions and/or agreements. Asdescribed briefly in the example above, proposed changes are accepted orrejected by those managers who are responsible for various dependencyrelationships within DVE projects. At the same time, proposed changes toe-commerce agreements can be initiated, negotiated, and accepted. In theprior art, these actions within the electronic marketplaces would beseparate considerations that would not be electronically integrated intothe decision-supporting applications within an enterprise; in contrast,with the present invention, the dependency relationships that arecreated by an enterprise's e-commerce agreements for acquiring goods andservices are integrated along with the other dependency relationshipswithin the enterprise that are necessary for ensuring the successfulcompletion scenario for a DVE project. This advantage is illustrated inthe following scenario concerning the manipulation of cost efficiencyinformation.

In this example, a purchasing agent examines if switching to a cheaperpower supply will decrease the cost of a DVE project. The purchasingagent opens a DVE-enabled application with a purchasing view of the DVEproject in accordance with the purchasing agent role of the employee assupported by the DVE view assembly engine. The purchasing agent can addanother vendor of power supplies to the DVE project, thereby creating anew DVE object within the DVE project. The DVE enabling engine willregister the change and will associate the new DVE object throughappropriate relationships to other DVE objects by notifying the otherDVE objects of the presence of the new DVE object within the DVEproject.

The current contract for power supplies contains prearranged dropshipments. The DVE object for the power supplies indicates that aproposed change in the provided quantity requires a full renegotiationof contract terms and does not include a previously negotiated change inprice for different quantities. The current supplier has fixed terms ofcontract termination which impose high penalties, and this type ofinformation could be displayed on the financial manager's view of theDVE project. At the same time, alternate DVE objects could have beenderived from available information within an electronic marketplace,such as a proposed CPA from a different supplier. In this example, theDVE object for the alternate supplier does not impose a high changepenalty, and the financial manager's view shows that the proposed changein the DVE project can use the reduction in the contract amount with thealternate DVE object to offset the penalties that are imposed by thecurrent supplier, as determined by the DVE costing engine. Hence, thefinancial manager may give a qualified approval to the proposed changesuch that the proposed change is forwarded to the other DVE objects inthe DVE project based on the dependency relationships among the objects,which may be assisted by the change-notification registry. Onedependency for the power supply DVE object may indicate that productengineering has a requirement that all power supplies must meet ruggedmilitary-level specifications. If such information is missing from thee-commerce agreement associated with the proposed power supply, then apurchasing agent might be notified to communicate with the alternatesupplier to determine the technical specifications of the proposed powersupply. After a purchasing agent has verified that the proposed powersupply meets these requirements, then an engineering manager may provideengineering approval. After a financial manager has approved the changein forecasted profits, the proposed change could be accepted, and theappropriate e-commerce agreements and/or transactions could be initiatedwithin the electronic marketplace.

With reference now to FIG. 9, a flowchart depicts a process for usingthe DVE project views that are provided by DVE-enabled applications. Theprocess begins with a user, such as an enterprise employee, opening aDVE-enabled application (step 902). The user selects a DVE project (step904), and an appropriate DVE project view is created (step 906); asnoted above, the user may be restricted to the types of views that maybe accessed by the user based on the user's employee group or role. Theuser then manipulates the GUI controls/objects of the DVE-enabledapplication that represent DVE object to investigate possible changes tocosts, schedule dates, or other DVE object properties as desired (step908). The ability of the user to manipulate these parameters are limitedby the DVE-enabled application such that the dependency relationshipsamong the DVE objects are maintained.

When the user has determined to propose a change in a DVE project, otherusers and/or objects are automatically notified based on registerednotification preferences in the DVE project or based on the DVE objectrelationships among those DVE objects that are affected by the proposedchange (step 910). In addition, changes to the appropriate e-commerceagreements are also initiated within the appropriate electronicmarketplaces in accordance with the proposed change to the DVE project(step 912). The required approvals are subsequently collected by theDVE-enabled application (step 914), after which the user can requestactivation of the proposed change such that the proposed change isincorporated into the project completion scenario (step 916). Therequired approvals would also include the arrangement of potentiale-commerce agreement modifications, and the activation of the proposedchange would initiate the commitment of the enterprise into newagreements within an electronic marketplace (step 918).

With reference now to FIG. 10, a flowchart depicts a more detailedprocess by which a DVE project examines the dependency relationshipsamong its DVE objects for a proposed change in a DVE project. A user isable to manipulate GUI controls/objects that represent DVE objects, andthe variations in the parameters of the GUI objects represent changes inthe variable values within a DVE object, such as delivery date, objectspecifications, or costs associated with a DVE object (step 1002). Whena user has input a possible change to an associated DVE object, thepotential change is temporarily stored (step 1004).

The associated DVE object then checks whether the possible changeviolates the constraints within the DVE object for the given variablethat might be changed (step 1006). If the constraint for the variablewithin the DVE object would be violated, then a graphical indicationwithin the user's view in the DVE-enabled application could be presentedto notify the user that the potential change is not possible based on aparticular constraint, or the user is simply prevented from manipulatingthe GUI objects or controls in the user's view through which a userwould request the change (step 1008), thereby preventing the user fromproposing the change in the variable. For example, if a user is slidinga GUI object along a graphical timeline to change the schedule datesassociated with a DVE object, the DVE-enabled application would preventthe user from moving the GUI object to a position that would selectschedule dates that are not possible in accordance with constraintswithin the associated DVE object. However, if no constraints areviolated, then the user would be allowed to input selections or GUIactions that indicate that the user desires to propose a change to a DVEobject or DVE project (step 1010). The DVE project, through its ownmethods, computes the impact of the proposed change upon other DVEobjects and possibly upon other DVE projects (step 1012). If otherpersonnel are viewing the DVE project, then those views would capturethe proposed change and present any appropriate impacts on those views(step 1014). For example, if a purchasing agent were to propose a changewithin a DVE project, then a financial manager that is viewing the DVEproject would be presented with the financial impacts of the proposedchange. After the proposed change is accepted and finalized as noted inFIG. 9, then the other project views would also capture the approvedchanges within a permanent view of the modified DVE project (step 1016).

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that some of theprocesses associated with the present invention are capable of beingdistributed in the form of instructions in a computer readable mediumand a variety of other forms, regardless of the particular type ofsignal bearing media actually used to carry out the distribution.Examples of computer readable media include media such as EPROM, ROM,tape, paper, floppy disc, hard disk drive, RAM, and CD-ROMs andtransmission-type media, such as digital and analog communicationslinks.

The description of the present invention has been presented for purposesof illustration but is not intended to be exhaustive or limited to thedisclosed embodiments. Many modifications and variations will beapparent to those of ordinary skill in the art. The embodiments werechosen to explain the principles of the invention and its practicalapplications and to enable others of ordinary skill in the art tounderstand the invention in order to implement various embodiments withvarious modifications as might be suited to other contemplated uses.

What is claimed is:
 1. A system, comprising: one or more memory devicesor storage components adapted to store electronic agreement information;and one or more processors in communication with the one or more memorydevices or storage components and adapted to: receive a plurality ofelectronic agreements regarding a project for a business entity; extractdependency relationships between specific parameters from the electronicagreements; receive, within the business entity, a proposed changeregarding at least one of the parameters; and compute an impact theproposed change would have on other parameters.
 2. The system of claim1, wherein the specific parameters comprise a date, cost, delivery,object specification, schedule, or a combination thereof.
 3. The systemof claim 1, wherein the one or more processors is further adapted todetermine that the proposed change modifies another parameter.
 4. Thesystem of claim 3, wherein the one or more processors is further adaptedto generate a modified electronic agreement that seeks the proposedchange.
 5. The system of claim 3, wherein the one or more processors isfurther adapted to notify relevant personnel within the business entityof the proposed change.
 6. The system of claim 5, wherein the one ormore processors is further adapted to collect approvals from therelevant personnel within the business entity.
 7. The system of claim 1,wherein the one or more processors is further operable to receive inputthat places a limit or lock on a specific parameter so that it cannot bechanged.
 8. A method for evaluating changes to a project for a productor service for sale by a business entity, comprising: receiving aplurality of electronic agreements regarding the project for thebusiness entity; extracting, by one or more hardware processors of aservice provider, dependency relationships between specific parametersfrom the electronic agreements; receiving, within the business entity, aproposed change regarding at least one of the parameters; and computingan impact the proposed change would have on other parameters.
 9. Themethod of claim 8, wherein the specific parameters comprise a date,cost, delivery, object specification, schedule, or a combinationthereof.
 10. The method of claim 8, further comprising determining thatthe proposed change modifies another parameter.
 11. The method of claim10, further comprising generating a modified electronic agreement thatseeks the proposed change.
 12. The method of claim 10, furthercomprising notifying relevant personnel within the business entity ofthe proposed change.
 13. The method of claim 10, further comprisingcollecting approvals from the relevant personnel within the businessentity.
 14. The method of claim 8, further comprising receiving inputthat places a limit or lock on a specific parameter so that it cannot bechanged.
 15. A non-transitory machine-readable medium comprising aplurality of machine-readable instructions which, when executed by oneor more processors, are adapted to cause the one or more processors toperform a method comprising: receiving a plurality of electronicagreements regarding a project for a business entity; extractingdependency relationships between specific parameters from the electronicagreements; receiving, within the business entity, a proposed changeregarding at least one of the parameters; and computing an impact theproposed change would have on other parameters.
 16. The non-transitorymachine-readable medium of claim 15, wherein the specific parameterscomprise a date, cost, delivery, object specification, schedule, or acombination thereof.
 17. The non-transitory machine-readable medium ofclaim 15, wherein the method further comprises determining that theproposed change modifies another parameter.
 18. The non-transitorymachine-readable medium of claim 17, wherein the method furthercomprises generating a modified electronic agreement that seeks theproposed change.
 19. The non-transitory machine-readable medium of claim17, wherein the method further comprises notifying relevant personnelwithin the business entity of the proposed change and collectingapprovals from the relevant personnel.
 20. The non-transitorymachine-readable medium of claim 15, wherein the method furthercomprises receiving input that places a limit or lock on a specificparameter so that it cannot be changed.